Detect cases where ::set_modifiable_text() would omit a leading newline from its input and adjust accordingly. This is done by adding an additional leading newline (that is ignored by HTML parsers) in case a leading newline is detected in the input.

This follows the HTML parsing rules for TEXTAREA, PRE, and LISTING elements that ignores a single U+000A LINE FEED character immediately following the open tag. It also respects the guidlines on newline normalization, so a U+000D CARRIAGE RETURN also triggers the extra newline.

The ::set_modifiable_text() method on WP_HTML_Tag_Processor and WP_HTML_Processor will fail to include a leading newline in the provided plaintext content on the first text of TEXTAREA, PRE, and LISTING elements.

This is due to special rules for these elements that cause a single leading newline to be ignored immediately following the open tag.

$html_processor = WP_HTML_Processor::create_fragment('<textarea></textarea>');
$html_processor->next_token();
$html_processor->set_modifiable_text( "\nAFTER NEWLINE" );
var_dump( $html_processor->get_modifiable_text() );
// string(13) "AFTER NEWLINE"
echo $html_processor->get_updated_html();
/* Prints:
<textarea>
AFTER NEWLINE</textarea>
*/

Note that the newline is present in the updated HTML, however the HTML parsing rules cause the leading newline to be ignored.

When rendered in the browser, this TEXTAREA element will report its .textContent as AFTER NEWLINE (with no leading newline) and the rendered element shows AFTER NEWLINE on the first line of the input box.

In order for the TEXTAREA to begin with a newline in its content, an additional newline must be included.

This is closely related to #64607.

Trac ticket: https://core.trac.wordpress.org/ticket/64609

Related ticket PR: #10871

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.